home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / ip / ppp / doc / mit.slfp.Z / mit.slfp
Encoding:
Text File  |  1991-10-31  |  6.9 KB  |  153 lines
  1. $9700 format=portrait side=newfront
  2. 1    MNET:MIT.SLFP               Last updated: 10 November 1987
  3.   
  4.      This file contains technical documentation of the MIT Serial Line
  5.      Framing Protocol, as implemented in the Merit Computer Network.
  6.      It was retyped from the original information from MIT on 11/10/87.
  7.  
  8.                 Appendix I:  Serial line Framing Protocol
  9.   
  10.           (This description is from a very old file written  when  we
  11.      were   first  implementing  the  protocol.   Details  are  still
  12.      accurate, though.)
  13.   
  14.           This  is  preliminary  documentation  on  the  serial  line
  15.      protocol  used  between  the  IBM  PCs  and the PC Gateway.  The
  16.      protocol has two levels: the low-level protocol  (LLP)  and  the
  17.      local  net  protocol.  The low level protocol wraps a packet and
  18.      delivers it to the PC Gateway.  The local net protocol tells the
  19.      PC Gateway what kind of packet it is.  Currently there two types
  20.      of packets: Internet and Address Request.  When the  PC  Gateway
  21.      receives  an  Internet  packet,  its  action  is  to forward the
  22.      internet packet  to  a  process  which  checks  the  packet  for
  23.      validity and then sends it to the net.  On receipt of an Address
  24.      Request  packet,  the PC Gateway sends an Address Request packet
  25.      back to the PC with  four  bytes  of  data  (the  PC's  internet
  26.      address) in the body of the packet.
  27.   
  28.           Neither  the  LLP  nor  the  local net protocol provide for
  29.      prioritized transmissions, checksums or  complex  line  control.
  30.      They  are  merely  a  simple  way  to  get  packets  to and from
  31.      machines.
  32.   
  33.           The local net protocol consists of a four byte leader.  For
  34.      an internet packet, this leader is:  2,1,0.0.   For  an  Address
  35.      Request, the leader is 2,3,0.0.  There is no data in the Address
  36.      Request  packet sent from the PC; it is only the four byte local
  37.      net header wrapped in the serial line protocol.
  38.   
  39.           The receipt of any packet with a local net header that does
  40.      not identify the packet as either internet or address request is
  41.      an error and the receipt of such a packet should be  logged  and
  42.      the packet discarded.
  43.   
  44.           LLP  consists  of  four  bytes  with  special meanings when
  45.      received over the serial line.  These are: ESC,  REQ,  ACK,  and
  46.      END.
  47.   
  48.           A packet is enclosed in a REQ and an END.  When a PC wishes
  49.      to  send  a  packet  it first sends a REQ to the PC Gateway.  It
  50.      then waits a suitable length of time to receive an ACK from  the
  51.      PC  Gateway.   If  no  ACK  byte  is received, the PC Gateway is
  52.      assumed to be unable to  handle  the  packet  right  now  and  a
  53.      timeout is said to have occurred.  The PC may either retry, wait
  54.      or return an error.
  55.   
  56.           After  the PC receives the ACK signal, it may begin sending
  57.      the packet.  The first four bytes of the packet  should  be  the
  58.      local  net header and an error will occur if they are not valid.
  59.      When the PC has completed sending the packet, it should send  an
  60.      END  byte to the Gateway.  The PC gateway will then consider the
  61.      packet and act upon it.
  62. 1                                                                   2
  63.   
  64.   
  65.           The PC Gateway goes through a similar process when it sends
  66.      a packet to a PC; only the roles are reversed.  It is  an  error
  67.      for  the  PC  Gateway to send a PC its address if the PC has not
  68.      requested its address from the Gateway.
  69.   
  70.           If a machine should receive a REQ  embedded  in  a  packet,
  71.      this  indicates  that the END signal was dropped somewhere.  The
  72.      receiving machine should drop the packet it  was  receiving  and
  73.      begin to receive a new one.  ACKs may be mixed inside packets to
  74.      allow  immediate  response  to REQs.  The receipt of an ACK by a
  75.      machine should be duly logged (and perhaps appropriately ignored
  76.      if the PC doesn't have an outstanding request).
  77.   
  78.           The final code, ESC, is used to allow the characters  whose
  79.      codes  are  used  by ESC, REQ, ACK and END to appear in packets.
  80.      Receiving an ESC indicates that the next byte should  be  looked
  81.      at  to  produce  the  correct character.  Here is a table of the
  82.      codes for the signals and the ESC sequences to produce the  data
  83.      whose codes they use.
  84.   
  85.      ESC      242       ESC 0
  86.      REQ      243       ESC 1
  87.      ACK      244       ESC 2
  88.      END      245       ESC 3
  89.   
  90.           A  simple  way to unstuff the bytes is to add the character
  91.      following an ESC to the ESC to get the correct code and then put
  92.      it in the packet as data.  It is an error to have any  character
  93.      >3 follow an ESC.
  94.   
  95.           If  a machine receives any character other than a REQ or an
  96.      ACK when it is not in the process  of  receiving  a  packet,  it
  97.      should discard that character.
  98.   
  99.           Low-level  protocol  specification: IBM to Gateway, Gateway
  100.      to IBM.
  101.   
  102.           The following ASCII codes are used as flags in  the  manner
  103.      specified:
  104.   
  105.      242      - Prefix  code  for  sending  data  codes which are set
  106.                 aside for protocol use.
  107.      243      - Request to send (REQ).
  108.      244      - Acknowledge (ACK).
  109.      245      - End of packet (END).
  110.   
  111.           A typical data transfer occurs as follows:
  112.   
  113.   
  114.      IBM wants to send packet to Gateway:  It sends REQ and waits for ACK.
  115.      Gateway is ready to receive packet:   It sends ACK
  116.      IBM sends packet to Gateway followed by END.
  117.      The packet itself is encoded so that REQ,  ACK,  and  END  never
  118.      appear  in  the  text.  This is done by performing the following
  119.      substitutions:
  120. 1                                                                   3
  121.   
  122.   
  123.      242 --> 242 0
  124.      243 --> 242 1
  125.      244 --> 242 2
  126.      245 --> 242 3
  127.   
  128.           Note  that  transfers  can   occur   in   both   directions
  129.      simultaneously.  However the ACK signal may be embedded within a
  130.      data packet and must be explicitly removed:
  131.  
  132.      IBM wants to send packet to Gateway:  It sends REQ and waits for ACK.
  133.      Gateway is ready to receive packet:   It sends ACK.
  134.      IBM starts sending packet.
  135.      Gateway wants to send packet to IBM:  It sends REQ and waits for ACK.
  136.      IBM is ready to receive packet:       It sends ACK.
  137.      IBM  continues  sending  its  packet, while Gateway sends a packet to
  138.      IBM.
  139.   
  140.           Timeouts may occur if the wait between a REQ and an ACK  is
  141.      too  long or no packet characters are transmitted for too long a
  142.      time.  In both cases no recovery action is undertaken: the other
  143.      system is assumed to have crashed.
  144.   
  145.           Receipt of protocol codes within  a  data  packet  has  the
  146.      following consequences:
  147.   
  148.      REQ      - End portion of data packet being sent has been lost.
  149.      ACK      - Should  be removed from input packet and its presence
  150.                 logged for  use  by  the  process  which  is  sending
  151.                 characters.
  152.      END      - Packet has been completely sent.
  153.